1. Field of the Invention
The present invention relates to a system and method for storing information, and more particularly to a system and method for storing information in a recoverable manner on an untrusted system.
2. Description of the Art
Many distributed applications must handle (i.e., process or store) information on untrusted systems. Some types of information (e.g., digital music, movies, etc.) should be protected against illegal use or copying. A common protection scheme is to encrypt the information and only allow the end-user's application program to decrypt and use it. The end-user application is provided by the owner or seller of the information (e.g., the content owner), and can be designed to be tamper-resistant or tamper-detecting, and thus provides a higher level of trustworthiness.
To perform its task, the end-user application must know and protect the key used to decrypt the information. It is possible for the user's application to have randomly picked the key when it was first recorded, but that leads to a problem. If there is nothing special about the keys (e.g., completely random), one user can give all the application, data, and keys to another user, and the information would be equally usable by the second user. Of course, the second user would not have paid for the original data. This is a problem.
Thus, merely placing the content (e.g., music) in any conventional database raises several problems. First, the user can give that database (e.g., the music) to a second user (e.g., his friend) and the user's friend gets the database/music without having paid for it.
Further, if one merely uses a play count (e.g., some of the music labels are interested in this aspect and provide a listener with a test play(s) (e.g., providing five free test plays before the user must buy it)) by placing a code or counter on the music (e.g., on the disk) to limit the number of plays that a user can hear, the user/hacker could find the counts and save the file with the count stored (or restored) at its original value. Thus, if the user can simply copy the database from system to system or save and restore them easily on the user's own system, then this is a problem.
Another problem is that, from time to time, users legitimately must update their personal computers, to improve the processor, to add or replace hard disks due to system crashes, etc. Such legitimate users typically would like to have their database (e.g., music) migrated from one computer system to another. Thus, depending on what the update is, customizing information needed for “secret keys” may no longer be correct, and the user may be in the unhappy position of being unable to play music, for example, that he has previously purchased.
Notwithstanding the above, it is extremely difficult to know absolutely which case is present (e.g., did the user fraudulently give the database to a friend or is the user legitimately updating his own computer system for his own use, etc.). Hitherto the invention, this has been a problem as there has been no system or method in which to store the local key on the user's machine for backup and update purposes which does not at the same time allow the backup/update mechanism to be used as a source of unauthorized copies.
Indeed, both the IBM Cryptolope® and the Intertrust digiBox® systems are able to protect intellectual property at a client station, and the recovery problem has been identified. That is, the IBM Cryptolope system as disclosed in U.S. Pat. No. 5,673,316, incorporated herein by reference, needs a central entity, the clearing center, to remember the usage conditions every client has. For crash recovery, preferably clients must “purchase” again all cryptolopes (i.e., pieces of content) they had before, and the clearing center will not charge them the second time. However, this is a complicated process, especially for clients with large content collections. Further, the Cryptolope system does not include a recovery mechanism other than repurchasing.
The Intertrust digiBox system can discover a backup operation being performed. However, there is no adequate recovery process and this is another example of an application in need of a good restoration process.